home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000003_news@newsmaster….columbia.edu _Mon Sep 29 16:11:08 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA09771
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 29 Sep 1997 16:11:08 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA06370
  7.     for kermit.misc@watsun; Mon, 29 Sep 1997 16:11:07 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!newsfeed.direct.ca!logbridge.uoregon.edu!news.bc.net!rover.ucs.ualberta.ca!alberta!not-for-mail
  9. From: Vladimir Alexiev <vladimir@cs.ualberta.ca>
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS?
  12. Date: 29 Sep 1997 13:53:25 -0600
  13. Organization: University of Alberta, Computing Science
  14. Lines: 58
  15. Message-ID: <omafgv99sa.fsf@tees.cs.ualberta.ca>
  16. References: <k1c7kBQEU5Wv@cc.usu.edu>
  17. NNTP-Posting-Host: tees.cs.ualberta.ca
  18. In-reply-to: jrd@cc.usu.edu's message of 26 Sep 97 22:11:11 MDT
  19. X-Newsreader: Gnus v5.0.15
  20. Xref: news.columbia.edu comp.protocols.kermit.misc:7764
  21.  
  22. In article <k1c7kBQEU5Wv@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  23.  
  24. >     Let's go through the PPP driver situation again when the driver
  25. > presents an Ethernet Packet Driver interface.
  26. >     PPP is a point to point link involving only two stations: this
  27. > end and the other end. It is not a broadcast medium, and thus ARP does not
  28. > apply. 
  29. pppd with the proxyarp option allows this. Here's what the pppd(8) man page
  30. says: 
  31.           Add an entry to this system's ARP  [Address  Resolution
  32.           Protocol] table with the IP address of the peer and the
  33.           Ethernet address of this system.
  34. Also, some terminal servers provide such proxy arp. At least the Cisco
  35. terminal server that runs at our uiniversity's login server. (Interestingly,
  36. it only does this when the user properly identified themselves to the server,
  37. otherwise it allows PPP, but does not give proxy arp.)
  38.  
  39. >     A PPP driver presenting an Ethernet interface is indistinguishable
  40. > from real Ethernet at the protocol stack level (i.e., by Kermit). That
  41. > driver must then FULLY simulate a broadcast medium of many stations, yet
  42. > they often fail completely to do that job.
  43.  
  44. I'm not saying that the Kermit class 1 handling is worse than than of other
  45. WATTCP apps. I suspect that Kermit does some more checks or expects more from
  46. the ethernet driver than other WATTCP apps, in other words it uses the
  47. ethernet driver more properly than other WATTCP apps. But the fact remains
  48. that these apps can use emulated class 1 drivers, while Kermit can't.
  49. Sometimes worse is better.
  50.  
  51. >  Half measures are failures too.
  52.  
  53. Well, these half measures prove to be adequate for other WATTCP apps.
  54.  
  55. >         SLIP is a point to point link. It is not an Ethernet-style
  56. > interface. Kermit knows about SLIP and treats it as a point to point
  57. > comms pathway without MAC addresses. Use SLIP interfaces.
  58.  
  59. What are the benefits of an ethernet interface to a SLIP interface:
  60. - there are apps that only support ethernet interfaces. Kermit couldn't
  61.   coexist with such apps because it demands a SLIP interface.
  62. - Ethernet interfaces support BOOTP. Is BOOTP impossible with a SLIP
  63.   interface? 
  64. - How about DHCP?
  65. - RARP is obviously impossible with a SLIP interface, but then it doesn't even
  66.   apply.
  67. - Is there anything else?
  68.  
  69. > There is no such thing as a standardized PPP interface, alas, and thus
  70. > Kermit does not have code to deal with the many PPP interfaces out there.
  71.  
  72. EtherPPP's documentation mentions class 15 (SLFP). Is that an example of a
  73. non-standardized PPP interface?
  74.  
  75. >     Avoid badly designed PPP drivers, please.
  76.  
  77. Since Kermit doesn't work with EtherPPP -k 1, does that make EtherPPP a badly
  78. designed driver too? How about Windows PPP drivers, do they support an
  79. Ethernet interface?